\section{Conclusions and future work}

In this paper, we have advocated first-class global environments as a
way of implementing the global environments mentioned in the \hs{}.
We have seen that this technique has several advantages in terms of
flexibility of the system, and that it greatly simplifies certain
difficult problems such as bootstrapping and sandboxing.

An interesting extension of our technique would be to consider
\emph{environment inheritance}.%
\footnote{We mean \emph{inheritance} not in the sense of subclassing,
  but rather as used in section 3.2.1 of the \hs{}.}
For example, an environment providing the standard bindings of the
\commonlisp{} language could be divided into an immutable part and a
mutable part.  The mutable part would then contain features that can
be modified by the user, such as the generic function
\texttt{print-object} or the variable \texttt{*print-base*}, and it
would inherit from the immutable part.  With this feature, it would
only be necessary to clone the mutable part in order to create the
evaluation environment from the startup environment as suggested in
\refSec{sec-native-compilation}.

We also think that first-class global environments could be an
excellent basis for a multi-user \commonlisp{} system.

In such a system, each user would have an initial, private,
environment.  That environment would contain the standard
\commonlisp{} functionality.  Most standard \commonlisp{} functions
would be shared between all users.  Some functions, such as
\texttt{print-object} or \texttt{initialize-instance} would not be
shared, so as to allow individual users to add methods to them without
affecting other users.

Furthermore, functionality that could destroy the integrity of the
system, such as access to raw memory, would be accessible in an
environment reserved for system maintenance.  This environment would
not be accessible to ordinary users.
